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Introduction 


Rhizome.org is an online platform for the global new media art community. Its 
programs and activities support the creation, presentation, discussion and 
preservation of new media art: a broad and flexible set of creative practices 
employing or responding to new technologies, including software, databases, 
network protocols, hardware, robotics, and multimedia tools. These practices 
take many forms, from web sites to performances and installations. New media 
art is often interdisciplinary, blurring the boundaries between established 
disciplines and involving artists and others in collaborative processes. Because 
new media technologies are themselves changing and converging at a rapid 
pace, the field is constantly in flux. 


The ArtBase is Rhizome's online archive of new media art’. Initially conceived 
and developed as an archive of net art projects exclusively, the scope of the 
ArtBase has since been expanded to include other forms of new media art, such 
as software, games, and web-based documentation of installation and 
performance works. The ArtBase includes works of historical significance that are 
submitted by the artists themselves, or by the owners of commissioned artworks, 
through an online submission process. The term ArtBase here refers to both the 
tools and system used to document the artworks as well as the artworks 
themselves. 


This paper outlines the key steps Rhizome should consider taking toward 
preserving the works of art included in the Rhizome ArtBase, and indicates 
measures Rhizome may take in the near future to test the strategy of emulation 
in particular. It outlines a general method for preserving new media art. Although 
it discusses some of Rhizome’s current policies, it also includes steps, which 
may be impractical for Rhizome to take at this stage. Overall, this paper defines a 
research agenda for a long-term new media art preservation project to be 
undertaken by the arts and cultural community in the future, with the ultimate 
goal of developing solutions for the preservation of new media art. It is thus both 
a working paper for Rhizome and a map of Rhizome’s contribution to the larger 
effort to preserve artworks in digital and other variable media. 


This effort builds on Rhizome’s existing systems for the submission, storage and 
display of artworks and their accompanying metadata (descriptive and technical 
information about the artworks). A key part of this system, the ArtBase Artist 
Questionnaire, gathers information necessary for guiding future preservation 
measures, including documentation, migration, emulation and reinterpretation. 
This questionnaire was developed in conjunction with the Guggenheim 
Museum’s Variable Media Initiative®. The testbed project proposed in this paper 
is a further step in the community-wide effort to develop a working strategy for 
preserving new media art, and dovetails with concurrent initiatives within the 


community, such as Archiving the Avant-Garde’, one of the first practical test 
cases preparing to use the strategy of emulation for preservation. Computer 
emulation has been proposed by Jeff Rothenberg in several papers to the digital 
libraries community as a strategy for preserving digital documents”, and has also 
been suggested as a partial preservation strategy for new media art®. 


Emulation as a Preservation Strategy 


One of the central problems facing preservationists in the future will be how to 
run old, obsolete software and documents on new systems. As a strategy for 
addressing this problem, emulation is especially suited to works of digital media 
art. Hardware emulation involves writing a new piece of software for a future 
computer that causes that computer to mimic, or emulate, all of the hardware 
behavior of an earlier computer. For instance, if one wanted to run a piece of 
software from 1999 (say a work from the ArtBase) on a computer in 2050, then 
one would write a piece of software called an “emulator” which would cause that 
2050-era computer to appear to all software as if it were an computer from 1999. 
Once this emulation software was in place, one could run the original software 
from 1999, including the operating system, the application program and all the 
document files. The original software would run because it interfaces to the 
computer itself through the emulator which translates all the requests of the 
original software into contemporary terms for the computer hardware and vice 
versa. This is not the only way one might preserve a work of new media art 
(other possible strategies include re-creating the work from scratch in 
contemporary media based on instructions from the artist, documenting the work 
with more stable media, and migrating the work to a newer standard or platform), 
but emulation could comprise one key component in an overall strategy intended 
to serve multiple goals. 


To understand emulation, it is helpful to outline the layers of which current 
computer systems are comprised. These layers form a ladder climbing from the 
bottom hardware/machine level to the individual document/file and include: 


Document/file 
Application/program software 
Operating System (OS) 
Hardware 


Rothenberg makes a strong case for emulating only the bottom, hardware, layer, 
and then running the original OS, application and document within the hardware 
emulator. He argues that hardware is well documented on a technical level, and 
that this approach gives us the most leverage for the investment (for the work of 
writing just a few hardware emulators, we could run dozens of operating 
systems, thousands of applications, and millions of documents). 


This strategy has potential advantages and disadvantages when applied to new 
media art. For instance, all current forms of emulation focus on the stand-alone 
computer and not the network per se. Many net artworks integrate the Internet 
into the work — for instance, calling in live data-streams from servers around the 
world. Emulation will never be able to emulate the entire Internet environment 
needed for some artworks, but there may be ways to mitigate this condition. One 
might be to record the specific types of network functionality the artwork relies 
on, so that this too may be emulated in the future. For instance, if a current work 
pings IP addresses on the Internet, but in the future both Ping and IP are 
obsolete protocols, then an IP-style number generator could take the place of 
real IP pinging in the future work. It is nonetheless likely that emulation will be 
able to preserve only some or most of the aspects of a work and that, in many 
cases, the emulated artwork will serve primarily as a snapshot or fragment to 
preserve some critical historical evidence in original form. Anyone involved in the 
preservation of art will recognize that well-preserved fragments can have great 
historical value. 


There are additional challenges to be overcome if emulation is to become a vital 
strategy for the preservation of new media art . For instance, will emulators be 
stand-alone applications or network-based application services? Will emulators 
be entirely server-based, or will they be able to divide functionality between 
server and client? These challenges are daunting, and raise significant artistic as 
well as technical issues, but the key fact is that they are surmountable, and the 
potential for preserving original new media art into the long-term is highly 
motivating. 


Recommendations 


Rhizome should take the following preparatory steps in anticipation of the future 
need for, and availability of, emulation software: 


1. Decide which metadata to capture or create about the original work of new 
media art and about the original software needed to actualize that work in 
the future. 

2. Make a tool for collecting and managing this metadata. 

3. Draft internal collection policies, which accommodate and document 
Rhizome’s archiving practices. 

4. Obtain and store legal copies of software, such as operating systems, 
browsers and plug-ins, required to run ArtBase artworks. 

5. Develop a strategy for preserving or migrating and storing the original 
software and original documents of the artwork needed for future emulations. 

6. Participate in collaborations with other institutions involved in the 
preservation of new media art, especially those projects which may address 
additional issues not addressed here, such as intellectual property rights 
around commercial software and developing emulation software. 


Metadata 


Metadata is "data about data." The term applies to records in the Rhizome 
ArtBase, as they contain information about data-based artworks. Rhizome will 
need to manage two types of metadata in the preservation process (some of this 
metadata is already captured and managed in the ArtBase). It is standard 
practice in the cultural heritage community to identify at least three types of 
metadata: descriptive (information which is used to search for, identify, and 
explain the artwork being described); administrative (information needed for the 
internal management of the artwork such as legal, storage, and non-public 
provenance information); and technical (information about the infrastructure and 
materials of an artwork necessary for preservation and handling). Rhizome 
should capture or create these three types of metadata, once for the artwork and 
again for the technology. 


1. Metadata about the original artwork (artwork metadata). This includes: 


A. Descriptive metadata (creator, date, genre, etc) that is already stored 
in the ArtBase database and is used for discovery and display. 

B. Administrative metadata (who owns rights to reproduce work, what 
parameters have the artist and/or current repository imposed for future 
recreations of the work, what is the general structure of the work, 
where are the actual files stored, etc). 

C. Technical metadata (what technologies are used to run the work, what 
is the function of each, etc). 


2. Metadata about the original software/technology needed to run the work 
(technology metadata). : 


A. Descriptive metadata (creator of software, date and current version, 
type of software, etc). 

B. Administrative metadata (who owns right to run or modify code, what 
are the parameters of such rights such as time limitations, platform 
limitations, limitations on purpose, where actual application files are 
located, the general structure and what other software is required for 
running, etc). 

C. Technical metadata (what bottom-level code was used to create 
software; for example, Flash was written in C++). 


It is recommended that these two categories of information—one about the 

artwork itself, the other about the technology needed to run it—be maintained 
separately. It should be noted that while emulation requires metadata about 

original software, emulation is but one strategy that may run concurrently with 
other strategies such as re-creation, in which case metadata from the artwork 
becomes “unhitched” from metadata about the original software. It also keeps 
clear the distinction between the original artwork and the mechanisms used to 


represent it (such confusion often arises in museum databases with regard to 
metadata about an original object and metadata about a digital image of that 
object). The distinctive relationship between content/vehicle and 
original/derivative is similar in both cases, and may be valuable in the future as 
different presentation approaches are brought to bear on a single work of art. 


It is equally important that the metadata created for this be consistent with other 
metadata standards in the arts and cultural heritage communities. This is to 
support the long-term maintenance of ArtBase metadata, to make it possible to 
integrate this metadata into existing collection management software as a way of 
ensuring that it can be used in daily institutional practice, and lastly to enable the 
integration of information about new media art collections with information about 
other types of collections from different institutions. In this last way, records of 
works of new media art from the ArtBase can be integrated with records of works 
in other variable media (installation, performance) and in fact traditional media 
(painting, sculpture) in large, union databases of works from several institutions 
such as “Museums and the Online Archive of California,”’ “Art Museum Image 
Consortium”® and others. 


Below is a suggested metadata scheme for the ArtBase and a crosswalk of other 
current metadata standards. The first column on the left indicates a set of 
elements based on a sub-set of the Dublin Core (an international digital library 
standard for describing digital documents of any type’), which is cross-walked 
with artwork metadata and then technology metadata in the next two columns. 
The next three columns provide equivalent elements in three other metadata 
standards: the Encoded Archival Description standard for describing collections 
used by archives worldwide"; the Categories for Description of Works of Art, 
developed by the Getty for museum art cataloging''; and MARC, the 
bibliographic record format standard used in libraries from the Library of 
Congress to local public libraries'*. In a simple database management system, 
each metadata element could be the equivalent of one database field, but in 
more complex systems, each element may instead comprise a category of sub- 
fields. One field in particular (Artwork / description / variable media) will definitely 
need to be expanded to include additional relevant metadata such as that 
outlined in current and future iterations of the Variable Media Questionnaire 
which documents appearance, functions, and behaviors of the work separate 
from any one technology — allowing it to be re-created with different technology in 
the future. The element set below provides for three functions: standardized core 
cataloging data for management and access; documenting the original state of 
the work (at time of submission to ArtBase); and recording information needed 
for future emulation. Collecting this last type of data, in addition to the Artist’s 
Questionnaire metadata, will allow the ArtBase in the future to choose among 
emulation and re-creation strategies for various purposes. 


Information about hardware is indicated below not for the purposes of hardware 
preservation but rather because an emulator must know which hardware to 


mimic. In some cases, hardware may also indicate physical installation 


components of a new media artwork. The addition of metadata for 
hardware/physical aspects of the artworks both enables emulation and also 
serves to update the current ArtBase metadata schema to allow for works, which 
have either or both digital and physical components such as gallery installations 
or robotic components. Below, each element/field is indicated in the table in black 
text; possible values and types of values for each field appear as italicized text. 


DC ArtBase ArtBase Encoded CDWA MARC 
Element Artworks Technology * Archival 
Description 
title title name unittitle title title (245) 
Letters Flash or 
Through Time | Macintosh G4 
creator artist creator origination | creation-creator title (100) 
Richard Macromedia Inc. 
Rinehart or 
Apple Computer 
Inc. 
subject genre subject subject matter — subject 
net art index terms (6xx) 
description | keywords, description, scopeconte | descriptive note note (520) 
email, interface- nt 
memory controller 
biography, network role 
born in... server-side 
statement, or 
|! remember... | client-side 
original url 
http://coyoteyi 
variable 
media 
questionnaire 
elements of 
appearance, 
function, and 
behavior 
date date created date released unitdate creation- date publish 
01/23/1999 09/22/1999 (260) 
type Type Type genreform | object type (007) 
interactive Browser or 
Plug-in or 
Server or 
robotics 
identifier Unique ID unitid repository no. note (024) 
09933 
current url 
http:/rhizome 
contributor | Contributors — | co-creators — origination | creation- anywhere 
agents * partners commission (700) 
Commissione | Torchmate Inc. 
r: New 


Langton Arts 


format Links to format physdesc materials - (007) 
software & application or techniques 
hardware os or 
(See at right) | hardware or 
installation 
language Human base code lang inscriptions 
language * C++ 
English 
publisher current current owner - repository current locate — reproductio 
presenter * distributor repository name n 
coyoteyip Macromedia Note 
(533n) 
rights rights and rights and admininfo copyright - rights 
parameters permissions restrictions (540a) 
owners & owners & 
restrictions restrictions 
coverage version *, version *, geogname | measurements publish 
10 4.0 or (651) 
storage size, | PPC 604 chip 


15mb 
storage 
location *, 
CD no. 15 


storage size 
* 


45mb 
storage location 


CD no. 16 


* indicates new field, in addition to existing ArtBase metadata elements 


The basic one-to-many record structure, which relates one artwork to the many 
types of technology needed to present it, might look like the following example 
(see diagram on following page). This example indicates that a full record exists 
in the ArtBase for one work of new media art, including all the metadata elements 
above such as creator, type, rights, format, etc. Links extend from the ‘format’ 
field in that record to the many related records in the Technology Database, 
which also comprise full records of creator, type, rights, etc. 


Artwork Database 
Record (new media artwork) 
Format field 
Technology Database 
Record (server/hardware) 
Sun Sparc Server 
Technology Database 
Record (client/nhardware) 
Intel desktop 
Technology Database 
Record (server/OS) 
Unix BSD 4.0 
Technology Database 
Record (client/OS) 
Windows 2000/me/NT 
Technology Database 
Record (server/application) 
Perl 5.0 
Technology Database 
Record (client/application) 
Netscape 5.0 


Currently, Rhizome allows artists who are submitting artworks to the ArtBase to 
enter metadata about their works. The Rhizome ArtBase Coordinator then 
reviews this artist-provided metadata and revises it as necessary before making 
it available to the public via the Rhizome.org web site. It is recommended that 
this metadata generation and review strategy be kept as is for the time being, 
altered only in that artists are asked to submit the expanded metadata above. In 
the case of metadata about the artwork itself, each artist should be required to fill 
out all fields. In the case of metadata about the technology needed to run the 
artwork (note: not to author/edit the work), the submitting artist may choose from 
a list of pre-entered hardware and software records (such as those indicated in 
red in the example above.) These records are very similar to those already in 
place in the ArtBase submission form; but are here made explicit and more 
detailed in a separate technology database/table. If the correct record for a piece 
of technology does not exist in the system yet, the submitting artist may choose 
to create a new record. 


It should be explicit to the submitting artist that they should select only as many 
technology choices as are minimally necessary to run the work (server OS, 
client-side software, plug-ins, etc.), but that they need not choose every possible 
configuration under which their work may run, just the one configuration under 
which their work runs best. It should also be noted that not every technical detail 
about a given software application or hardware platform need be exhaustively 


recorded in the ArtBase; such technology is better documented on a technical 
level elsewhere, but the ArtBase needs to relate such technology to specific 
works of art, and to contain sufficient detail about such technology to allow 
accurate identification of it well into the future. 


Tools 


It is recommended that the tool for managing both sets of metadata above be 
constructed as a relational database with two separate tables. Since a 
PHP/MySQL tool already exists at Rhizome for collecting ArtBase submissions 
online, perhaps it could be adapted and expanded to include the above 
metadata. However, years of museums’ experience in this field suggest that 
consideration should be given to using two tools; one for metadata gathering and 
public access online; another for internal metadata management. Whether 
Rhizome chooses to build one integrated tool or separate tools, one table in the 
artwork database should have a record for each artwork with a link to all relevant 
records in the technology database. Conversely, the technology database should 
have records for each instance of software, with links to all artworks that use that 
software. 


Rhizome could develop a prototype tool using FileMaker Pro, MS Access or 
MySQL. This tool would need to be developed in an iterative manner to 
accommodate changes in the preservation methodology. One suggested 
strategy for near-term further development is to become involved or keep aware 
of other current tool development projects in the arts and cultural heritage 
community. For instance, the Berkeley Art Museum and the MOAC consortium 
have developed the “Digital Asset Management Database” (DAMD)'*. DAMD has 
two features that may be of interest to the Rhizome and other digital preservation 
efforts. First, the DAMD architecture includes a complex rendering of the 
structure of a work, such as that indicated in the example above. In DAMD, one 
can catalog all the parts of an artist book and then relate each component to a 
multimedia representation. In the case of an artist book, this allows one to record 
the intellectual structure of the book (chapters), the physical structure (pages) 
and the virtual structure (digital images and transcriptions of pages). Similarly, 
new media artwork records could benefit from being broken down into 
component parts, with the appropriate technology/software records being linked 
into the appropriate components. DAMD also allows records to be exported into 
standards-based formats such as EAD, TEI, and METS flavors of XML, allowing 
the data to be shared outside the boundaries of any one organization. Whatever 
the strategy for development of this tool at Rhizome, it is recommended to start 
with a fairly simple metadata scheme and plan on updating the tool concurrently 
with any updates to metadata scheme or functional needs. 
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Collection Policy 


Rhizome has implicit collection policies for acquisition and long-term 
maintenance of works in the ArtBase in the form of the ArtBase Linked Object 
Agreement and ArtBase Cloned Object Agreement. It is recommended that these 
agreements form the core of a more formal internal collection policy such as the 
recently drafted "Rhizome ArtBase Management Policy." Such a policy should be 
informed by the experience represented in most traditional museum collection 
and acquisition policies. This policy would, among other things, spell out in 
greater detail the internal functions that are mentioned in the ArtBase Artist 
Agreement, such as, “We also intend, but are not obligated, to provide access to 
obsolete software and to implement measures to preserve your artwork, such as 
documentation, migration, emulation and reinterpretation, as indicated in the 
Artist Questionnaire.” On this point for instance, it is recommended that this 
working paper constitute the amendment to the collections policy that details 
Rhizome’s specific strategy to “provide access to obsolete software and to 
implement measures to preserve your artwork....” On other points, the collection 
policy should specify what metadata will be created upon acquisition of a work 
either by the artist or by internal agents, what constitutes a minimal/core record 
(the metadata above is offered for these), and should specify organizational roles 
and responsibilities in detail. For instance, who has final approval of what gets 
included in the ArtBase? Who has final authority over what works are preserved? 
What are the exact mechanisms for obtaining updates from the artists and what 
constitutes a ‘good effort’ to contact the artist? What are the de-acquisition 
policies for works that will no longer be included or preserved? In addition, this is 
where Rhizome can internally outline strategies for backup, data quality control, 
and security provisions. It should be noted that a collections policy for Rhizome, 
as for any cultural institution, is more than a legal document that safeguards 
Rhizome; it is a working document and training manual for Rhizome 
professionals, and an expression of the commitment and limits of Rhizome 
beyond those with direct legal implications. 


Obtain and Store Copies of Software 


Rhizome should not, at this point, seek all the permissions necessary to preserve 
copies of unique or commercial software (such as operating systems, browsers 
and plug-ins) for the purposes of future emulation and presentation, but should 
rather leave this as a future project for the larger cultural community. At this 
point, Rhizome should operate within the existing compound of software licenses, 
which are usually flexible enough to allow one copy of the application software 
and one backup copy of the software to be kept for emergency purposes. 
Rhizome should endeavor to purchase or otherwise obtain legal copies of 
software needed to run the artworks contained in the Rhizome ArtBase. This 
software should then be stored and maintained in an organized fashion (see 
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Storage Migration Strategy, below). Since emulation is not an immediate factor, 
this strategy should suffice for the near term. It is nonetheless clear that multiple 
intellectual property issues must be resolved before emulation can be adopted as 
a long-term strategy. 


Outdated versions of most commercial software have very limited commercial 
value when new versions are released. This fact, along with other factors such as 
charity tax-relief, should help motivate commercial software companies to reach 
mutually beneficial agreements with cultural organizations. 


Working out permissions and agreements for the re-use and potential 
modification of original software will be an absolute requirement for any 
organization using emulation as a preservation strategy. This work is perhaps 
better accomplished by a consortium effort, such as the Variable Media Network 
and Archiving the Avant-Garde project, where a collective of cultural agencies 
might have more bargaining power with commercial software companies and 
governmental agencies. Cultural agencies are encouraged to begin exploring 
legal options for preserving existing software such as fair use exemptions or 
other areas of the Digital Millennium Copyright Act"*. Additionally, issues around 
the long-term preservation of original software should continue to head the 
agendas of advocacy organizations such as the National Initiative for Networked 
Cultural Heritage ‘or Electronic Frontier Foundation’. 


Storage Migration Strategy 


Rhizome needs to have a backup and/or archiving strategy in place for at least 
three types of content: digital files comprising works of (cloned) art in the 
ArtBase; digital files comprising associated metadata (ArtBase database tools 
and files); and digital files of the original application software. 


It is recommended that metadata (database and associated files) not be 
archived, but kept ‘online’ as a working document. This database should be 
routinely backed up in case of emergencies, in the case of any updates or 
versions, and because this data has great value in the preservation effort. But 
this resource could be backed up via hard disk redundancy, tape, or other media, 
as the idea is to keep the metadata alive, up to date, and accessible. Fixed, 
outdated, historical copies of the metadata are unnecessary. However, for the 
other two types of content—new media artwork files and original software—a 
more ‘archival’ storage migration strategy is recommended. The basic idea is that 
the original files should not be changed at all in the preservation effort, but that 
the storage media on which they reside will need to be routinely changed or 
migrated. 


Original artwork files and original software will be needed to produce future 


emulations, so the digital files comprising the artworks and the original software 
should be copied onto backup copies of either an optical, read-only, fixed storage 
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medium such as CD-ROM (using ISO 9660 standard format) or data-DVD. 
Dynamic, re-writable storage such as hard disk or tape could also safely be used, 
if extra redundancy is built in to compensate for the risk of erasure. All original 
software documentation (manuals in print or digital form) should be maintained 
as well. Metadata about the location and CD number of each CD should be 
recorded in the metadata tool (artwork and technology databases) for future 
retrieval. This content should be reviewed at least once every three years to 
determine if migration to a new storage format is warranted. As with all backup 
media, one copy of each CD should be kept on-site at Rhizome, and another 
copy of each kept off-site, preferably in another city, but at the very least ina 
separate building. Rhizome should establish a regular schedule for copying and 
distributing new CD’s. 


This ‘archival’ strategy may seem to be at odds with any notion of the variability 
of new media artworks, but there are a few points that help reconcile this 
seeming contradiction. First, this strategy of keeping original software on fixed 
media supports the strategy of emulation, but emulation should form only one 
component of an overall preservation strategy. Emulation will in many cases 
recreate only a snapshot or partial function of a work of new media art. Second, 
while this effort to store original software in order to reproduce artwork does 
require maintenance of some original content, it actually serves to support 
variability as well. Preserving the original software saves us from having to 
preserve the original hardware by allowing the artwork to be reproduced on 
future, unknown, computer hardware through emulation. Third, if a work is 
completely re-created (as opposed to emulated) in the future, some or none of 
the original hardware or software may be used in that version of the work. 
However, good metadata records about what was used in the work’s original 
incarnation cannot help but inform all subsequent recreations. Last, most digital 
preservation strategies would include periodic migration of the storage media and 
the content (changing the format of all relevant media, software and files into 
contemporary formats). However, since the specific strategy of emulation is 
assumed here, the only component that needs to be migrated is the storage 
medium itself. Everything else remains in its original format. 


Conclusion on Emulation 


Because of the significant expense and time involved, Rhizome need not at this 
point undertake the experiment of testing the actual emulation of original 
software and artworks on it’s own. Rhizome is encouraged to participate in future 
collaborative projects where artwork emulation takes place. It is clear that such 
emulator software, written for the purposes of long-term preservation, will need to 
be itself based on international standards, hopefully in an open-source manner, 
and will need to operate at the hardware level (emulating a chip instead of any 
one operating system or application). The long-term preservation of culture 
cannot depend on the indefinite health of any one company which may own 
exclusive rights to proprietary emulation software. Individual vendors surely have 


14 


a role however in developing value-added emulator software and marketing and 
maintaining their version. Existing commercial emulators such as SoftPC provide 
areas of somewhat interesting experimentation, but since they emulate only the 
OS, and are completely proprietary, they cannot be relied upon for the long-term. 
Open-source or individual game emulators such as those written by game- 
hackers are an interesting model, but are even more limited for long-term 
preservation purposes because they are written to emulate one game platform 
(sometimes), or just one game/application (commonly). In addition, an individual 
is not a reliable maintenance agency for the long-term availability and 
maintenance of such emulation code. The bottom line is that we now have some 
interesting cases of emulators that show promise, but we still have work to do if 
we are to regard emulation as a long-term cultural preservation strategy. 


Rhizome will make a unique, significant and feasible contribution to digital 
preservation efforts by proposing and testing solutions for metadata and policy as 
outlined above. Rhizome is helping to set the stage for following efforts, such as 
the Variable Media Network, and Archiving the Avant-Garde, in which a larger 
consortium of organizations will undertake the costly project of commissioning an 
open-source hardware emulator. Other organizations wanting to take advantage 
of this future emulator are encouraged to refer to this document and to establish 
the appropriate metadata, storage, and policy solutions in order to prepare 
themselves for emulating artworks or other digital documents. 


Notes 


1. Rhizome.org 
http://rhizome.org 

2. ArtBase 
http://rhizome.org/artbase 

3. Variable Media 
http://www.quggenheim.org/variablemedia/ 

4. Archiving the Avant-Garde 
http://www.bampfa.berkeley.edu/ciao/avant_garde.html 

5. Avoiding Technological Quicksand: Finding a Viable Technical Foundation for 

Digital Preservation, Jeff Rothenberg 

http://www.clir.org/pubs/reports/rothenberg/contents.html 

6. Artwork The Straw that Broke the Museum's Back? Collecting and Preserving 

Digital MediaArtworks for the Next Century, Richard Rinehart 
http://switch.sjsu.edu/web/v6n1/article.htm 

7. Museums and the Online Archive of California 
http://www.bampfa.berkeley.edu/moac 

8. Art Museum Image Consortium 
http://www.amico.org 

9. Dublin Core 
http://www.dublincore.org 


ibe 


10. Encoded Archival Description 
http://www.loc.gov/ead 
11. Categories for the Description of Works of Art 
http://www.getty.edu/research/institute/standards/cdwa/ 
12. MARC 
http://www.loc.gov/marc 
13. Produce, Publish and Preserve: A Holistic Approach to Digital Assets 
ManagementGuenter Waibel 
http://www.bampfa.berkeley.edu/moac/imaging/index.html 
14. Digital Millennium Copyright Act 
http://www.loc.gov/copyright/legislation/dmca.pdf 
15. National Initiative for Networked Cultural Heritage 
http://www.ninch.org 
16. Electronic Frontier Foundation 
http://www.eff.org 


Richard Rinehart is Director of Digital Media at the Berkeley Art Museum/Pacific 
Film Archive, Digital Media Faculty in Art Practice at UC Berkeley, and is a 
net.artist. Richard can be contacted at rinehart@uclink.berkeley.edu. 


